| # Error Reporting |

The Java virtual machines (JVM) that ship with the Java 2 SDK (J2SDK) 1.4 and the Java 2 Runtime Environment 1.4 have an error-reporting feature first introduced in J2SDK 1.3.1. When the JVM detects a crash in native code such as JNI code written by the developer or when the JVM itself crashes, it will print debug information about the crash. This error message normally will include information such as the function name, library name, source-file name and line number at which the error occurred. (Currently, information about file name and line number are available only available on Microsoft Windows platforms.) For an example of a message emitted by the error handler, see JNI Error example.

The information provided by the new error-reporting mechanism will allow developers to more easily and efficiently debug their applications. If an error message indicates a problem in the JVM code itself, it will allow a developer to submit a more accurate and helpful bug report.

Sometimes the error-reporting mechanism won't be able to determine the information that might be helpful in locating the source of a crash. To get the most out of the error handler, developers should be aware of the following guidelines and limitations.

Compile in debug mode

> In some circumstances, the error-reporting mechanism won't be able to determine symbol names. The most common reason for this is that the binary code that crashed was not compiled in debug mode and therefore doesn't have symbol tables. Developers should compile their code in debug mode to ensure that it contains the necessary debug information. In Visual Studio, for example, this means choosing "Debug" rather than "Release" as the project's build mode. When using gcc or cc on Linux or on the SolarisTM operating environment, compile using the `-g` command-line option.

Non-exported functions

> Even without debug information in the binary code, the error handler can still print the function name of the crash site. However, the function name might not be correct if the problematic function is not "exported" from the dynamic library. On Linux and Solaris, all functions are exported except those declared static. On Microsoft Windows platforms, no functions are exported unless explicitly declared so (using `JNIEXPORT` or `__declspec(dllexport)`).

Visual Studio limitation on Windows 95/98 and Windows NT

> On Windows 95, Windows 98 and Windows NT platforms, the error handler uses the system's `imagehlp.dll` file to help determine the function name, source file, and line number of a crash site. (Windows 2000 and Windows ME use two files, `imagehlp.dll` and `debughlp.dll` to perform this task.) However, the `imagehlp.dll` file in Windows 95/98 and Windows NT does not work well with binary code and DLLs generated by Visual Studio 6.0. This problem is due to a file-format change introduced in Visual Studio 6.0 and is described in detail on the Microsoft Product Support Services web site along with Microsoft's recommended solution.

> This problem may cause the error handler to generate error messages with incorrect information about the function name, source file and line number of the crash site, though other information in the error message will be correct.

Copyright © 2002 Sun Microsystems, Inc. All Rights Reserved. |